Method and apparatus for performing pre-allocation of memory to avoid triggering garbage collection operations

ABSTRACT

The present invention provides a mechanism for enabling memory allocation operations to be deterministic. According to the invention, determinism is achieved by first pre-allocating a contiguous memory space, and then using that memory space to perform subsequent memory allocation operations. Because the subsequent memory allocation operations are performed using memory space that has already been allocated, it is ensured that the allocation operations will not trigger a garbage collection operation. Also, because the pre-allocated memory space is contiguous, there will be no fragmentation concerns. Thus, the present invention eliminates the two major causes of non-constant allocation times. By doing so, the present invention makes it possible to achieve determinism in a dynamic memory allocation system.

This application claims the benefit of U.S. Provisional Application No.60/094,007, filed Jul. 24, 1998.

BACKGROUND

This invention relates generally to computer systems and moreparticularly to a method and apparatus for achieving deterministicmemory allocation response in a computer system.

In many modem computer systems, memory needed for execution of programcomponents, such as objects, is allocated at run time rather than atcompile time. In such systems, whenever an object is created orinstantiated during execution, memory is dynamically allocated from amemory heap to accommodate the object. This memory may be used to holddata associated with the object, or to perform operations required bythe object. When the memory is no longer needed (for example, when theobject becomes obsolete), the memory is released back to the heap to beused for other objects. Different methodologies is exist for releasingmemory back to a memory heap. A common methodology is known as garbagecollection (GC).

With GC, the release of memory back to a memory heap is systemcontrolled. That is, the user (i.e. the application developer) controlswhen an object is instantiated, and hence, when memory is allocated, butit is the underlying system that controls when memory is de-allocatedand released back to the heap. Typically, a GC operation is triggeredwhen the amount of free memory space in the heap drops below a certainthreshold. This determination is typically made at the time ofallocating memory for a new object instance. Thus, a memory allocationoperation may (but does not always) trigger a GC operation. Whentriggered, the GC mechanism typically performs a trace to determinewhich object instances can be reached by the current program. All of thememory spaces associated with such object instances are marked as activeand are preserved. All of the other memory spaces (presumably associatedwith objects that are no longer reachable by the current program, andhence are obsolete) are recaptured and released back to the heap. Inthis manner, the GC mechanism collects the “garbage” memory spaces andreturns them to the heap.

As noted above, a memory allocation operation may trigger a GCoperation. Because of this possibility, the time needed to perform amemory allocation may vary greatly from allocation to allocation. Toillustrate, suppose that when a first memory allocation request isprocessed, the free space available in the heap is above a certain GCthreshold; thus, no GC operation is needed. As a result, this firstallocation is performed in an X amount of time. Suppose, however, thatwhen a subsequent memory allocation request is processed, the free spaceavailable in the heap has dropped below the threshold. In that case, aGC operation will have to be performed before the subsequent memoryallocation can be carried out. Thus, the time needed to perform thesubsequent memory allocation will be X+GCT, where GCT is the timerequired to perform the GC operation. Because GCT is substantialrelative to X, the time difference between the two memory allocationoperations is very significant.

While the triggering of a GC operation is a major factor in causingmemory allocation times to vary, it is not the only factor. Otherfactors such as memory fragmentation can also contribute to thevariance. If the memory in a heap is contiguous, it takes less time toallocate memory than if the heap were highly fragmented. Thus, thedegree of fragmentation of the heap can affect allocation times. Theseand other factors can cause memory allocation times to vary fromallocation to allocation.

In some implementations, it is important for memory allocationoperations to be deterministic, that is, to take substantially the sameamount of time each time the operation is performed, or to at least havethe allocation times be predictable. For example, in a real-timeimplementation, it is imperative for memory allocations to bedeterministic. Because of the potential for great variations in memoryallocation times, the typical allocation-garbage collection mechanismcannot be used in such implementations. Consequently, an improvedmechanism is needed.

SUMMARY OF THE INVENTION

The present invention provides a mechanism for enabling memoryallocation operations to be deterministic. The present invention isbased, at least partially, upon the observation that determinism may beachieved by first pre-allocating a contiguous memory space, and thenusing that memory space to perform the actual memory allocationoperations. Because the memory allocation operations are performed usingmemory space that has already been allocated, it is ensured that theallocation operations will not trigger a GC operation. Also, because thepre-allocated memory space is contiguous, there will be no fragmentationconcerns. Thus, the present invention eliminates the two major causes ofnon-constant allocation times. By doing so, the present invention makesit possible to achieve determinism in a dynamic memory allocationsystem.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a logical block diagram of a dynamic memory allocation systemin which the present invention may be implemented.

FIG. 2 is a flow diagram illustrating the operation of theDoPreallocated method of the Thread object in accordance with oneembodiment of the present invention.

FIG. 3 is a flow diagram illustrating the operation of the allocationmanager in response to a memory allocation request in accordance withone embodiment of the present invention.

FIG. 4 is a logical block diagram of a multi-threaded dynamic memoryallocation system in which the present invention may be implemented.

FIG. 5 is a flow diagram illustrating the operation of theDoPreallocated method of the Thread object in accordance with a secondembodiment of the present invention.

FIG. 6 is a flow diagram illustrating the operation of the allocationmanager in response to a memory allocation request in accordance with asecond embodiment of the present invention.

FIG. 7 is a hardware block diagram of a computer system in which thepresent invention may be implemented.

DETAILED DESCRIPTION OF THE EMBODIMENT(S)

With reference to FIG. 1, there is shown a logical block diagram of adynamic memory allocation system 100 in which the present invention maybe implemented. For purposes of illustration, the invention will bedescribed below with reference to a system based upon the Java™programming/execution environment developed by Sun Microsystems, Inc. ofMountain View, Calif. However, it should be noted that the presentinvention is not so limited but instead may be applied effectively toother platforms and systems.

As shown in FIG. 1, system 100 comprises a memory heap 102 foraccommodating dynamic memory allocations during program execution. Thememory heap 102 represents all of the dynamic memory space that isglobally available for use by program execution units, such as objects.THE memory heap 102 may have portions 104 which are occupied (i.e.portions which are Currently being used by objects) and portions 106which are free and available for allocation to new objects. As newobjects are instantiated during program execution, memory space isallocated from the free portions 106 of the heap 102. As old objectsbecome obsolete, their associated occupied memory spaces 104 arereleased back to the heap 102 for reuse by future new objects. In thismanner, the memory in the heap 102 is used and reused to accommodatedynamic memory allocation. In addition to the free 106 and occupied 104portions, the memory heap 102 may further comprise one or morepreallocated memory spaces 108. As will be explained further below, thispreallocated memory space 108 may be used to achieve deterministicmemory allocations in accordance with the present invention.

Management of the heap 102 is carried out by the memoryallocation/execution manager 110. Specifically, manager 110 controls theallocation of memory from the heap 102, and the release of memory backto the heap 102. In one embodiment, release of memory back to the heap102 is carried out by way of a GC operation. In addition to controllingthe heap 102, manager 110 also manages the overall operation andexecution flow of the system 100. In one embodiment, the manager 110takes the form of a Java™ virtual machine (Java™ VM), such as thatdescribed, for example, in The Java™ Virtual Machine Specification,Second Edition, by Tim Lindholm and Frank Yellin, Addison-Wesley, 1999,which is incorporated herein by this reference.

For purposes of managing the heap 102, the manager 110 comprises atleast two functions which may be invoked to perform memory allocations:(1) a “Normal” allocation function; and (2) a “Preallocated” allocationfunction. Under the Normal function, memory is allocated to new objectsfrom the free space 106 on the heap 102. This is a typical memoryallocation, and as with typical allocations, it can trigger a GCoperation if the free space on the heap is below a certain threshold.With the Preallocated function, on the other hand, memory is allocatednot from the free space 106 on the heap 102 but rather from thepreallocated memory space 108. Since this type of allocation isperformed on memory space 108 that has already been allocated, it isguaranteed not to trigger a GC operation. As described in greater detailbelow, the Preallocated function is used in the present invention toachieve deterministic memory allocation response.

System 100 further comprises a PreallocationContext object 112. Thisobject provides a means for referencing one or more of the preallocatedmemory spaces 108 on the heap. In one embodiment, when thePreallocationContext object 112 is instantiated, the constructor of theobject 112 causes a contiguous set of memory space 108 having a size N(the size N is specified at the time the object 112 is instantiated) tobe allocated on the heap. Once preallocated, this memory space 108 maybe used to perform subsequent memory allocations which are guaranteednot to trigger GC operations. At this point, it should be noted that theact of allocating the preallocated memory space 108 may cause a GCoperation if the free space 106 on the heap 102 is below a certainthreshold level. However, once the preallocated memory space 108 isallocated, then all subsequent allocations within the preallocatedmemory space 108 are guaranteed not to trigger a GC operation.

As to attributes, the PreallocationContext object 112 comprises a startpointer, a current pointer, and an end pointer. The start pointer pointsto the beginning 120 of the preallocated memory space 108 associatedwith the object 112, the end pointer points to the end 124 of thepreallocated memory space 108, and the current pointer points to thelocation 122 up to which memory has been allocated. The space betweenthe start pointer and the current pointer represents space which hasbeen allocated to objects. The space between the end pointer and thecurrent pointer represents free space which may be used to satisfyfuture memory allocation requests. When the object 112 is firstinstantiated, the start pointer and current pointer point to the samelocation 120 since no allocations have yet been performed.

System 100 further comprises a Thread object 114 which represents anabstraction of an actual thread of execution. When the Thread object 114is instantiated and its Start method is invoked, the Thread object 114is associated with an actual thread of execution, and the Thread object114 is used thereafter to maintain all of the context informationassociated with that thread of execution. The Thread object 114 has aplurality of methods and attributes associated therewith. These includean AllocFunction attribute and a DoPreallocatcd method.

The AllocFunction attribute specifies which memory allocation functionthe memory allocation manager 110 should use when performing memoryallocations for this thread of execution. If the AllocFunction attributeis set to “Normal”, then the manager 110 will use the Normal function toallocate memory for this thread. If the AllocFunction attribute is setto “Preallocated”, then the manager 110 will use the Preallocatedfunction to allocate memory for this thread.

The DoPreallocated method is invoked when it is necessary to achievedeterministic memory allocation behavior in a subsequent action. Morespecifically, the DoPreallocated method guarantees that all memoryallocations performed in association with the subsequent action will beperformed without triggering a GC operation and without suffering fromfragmentation effects. Thus, the allocations are performed insubstantially constant time. In one embodiment, the DoPreallocatedmethod is a static method (meaning that it is tied to the Thread objectclass as opposed to a specific Thread object instance), and it takes intwo parameters: (1) a Size parameter; and (2) an Action parameter. TheSize parameter specifies the size of the preallocated memory space 108that should be allocated when the PreallocationContext object 112 isinstantiated. The Action parameter provides an entry point to a set ofcode which is to be executed. The DoPreallocated method ensures thatwhile that set of code is executed, all memory allocations are made fromthe preallocated memory space 108. With all memory allocations beingmade from the preallocated memory space 108, no GC operations will beinvoked, and no fragmentation effects will be felt. Thus, substantiallyconstant time allocation, and hence determinism, is achieved in thememory allocation process.

With reference to the system diagram of FIG. 1 and the flow diagrams ofFIGS. 2 and 3, the operation of one embodiment of the present inventionwill now be described. Initially, suppose that the Thread object 114 hasbeen instantiated and that its Start method has been invoked so that theobject 114 has been associated with a thread of execution. Supposefurther that that thread of execution has been executing a set of codeand that during such execution, the thread encounters a DoPreallocatedmethod call which passes along a size parameter N and an Actionparameter AC. This causes the DoPreallocated method of the Thread objectclass to be invoked. Once invoked, the DoPreallocated method determines(204, FIG. 2) which thread invoked it. In this particular example, it isthe thread associated with the Thread object 114. Once thatdetermination is made, the DoPreallocated method instantiates (208) thePreallocationContext object 112, passing along N as the size parameter.During instantiation, the constructor of the PreallocationContext object112 causes a preallocated memory space 108 having a size N to beallocated on the heap 102. The start and current pointers are set topoint to the beginning 120 of the preallocated memory space 108, and theend pointer is set to point to the end 124 of the preallocated memoryspace 108. The preallocated memory space 108 is now ready for use.

In addition to instantiating the PreallocationContext object 112, theDoPreallocated method also sets (212) the AllocFunction attribute of theThread object 114 to “Preallocated”. This causes the allocation manager110 to perform all subsequent memory allocations for this thread usingthe Preallocated allocation function. Once the AllocFunction attributeis set, the DoPreallocated method causes the code referenced by theAction parameter AC to be executed (216). While executing this code, oneor more memory allocations will most likely need to be performed. Eachtime a memory allocation is needed, the allocation manager 110 isinvoked.

When invoked, the manager 110 receives (304, FIG. 3) the memoryallocation request. It then checks (308) the value of the AllocFunctionattribute of the thread that is making the allocation request. IfAllocFunction is set to “Normal”, then the Normal allocation function isused to perform (312) the memory allocation, in which case, theallocation is made from the free space 106 on the heap 102. Because thisis a normal allocation, it may trigger a GC operation. On the otherhand, if the AllocFunction attribute is set to “Preallocated” (as is thecase in this example), then the allocation manager 110 will use thePreallocated function to perform the memory allocation. Under thePreallocated function, the manager 110 does not allocate memory from thefree space 106 but rather from the preallocated memory space 108. As aresult, the memory allocation is guaranteed to not cause a GC operation,and to be free of fragmentation effects. By eliminating these two causesof unpredictability, it is possible to achieve deterministic behavior inthe memory allocation operation.

In one embodiment, memory allocation in accordance with the Preallocatedfunction is performed as follows. Initially, a determination is made(316) as to whether there is sufficient space in the preallocated memoryspace 108 to satisfy the memory allocation request. This may be done bycomparing the amount of free space (the space between the currentpointer 122 and the end pointer 124) in the preallocated memory space108 with the amount of space requested. If there is not enough freespace to satisfy the request, then an “out of memory” error is generated(324). No GC operation is invoked. On the other hand, if there issufficient space in the preallocated memory space 108 to satisfy therequest, then the memory allocation is performed (320) using thepreallocated memory space. In one embodiment, memory is allocated fromspace 108 by incrementing the current pointer of thePreallocationContext object by the amount of space used to fill thememory request. Memory allocation using a preallocated memory space 108is thus performed.

Referring again to FIG. 2, the set of code referenced by the Actionparameter AC continues to be executed until execution is completed. Atthat point, there is a return to the DoPreallocated method. Upon return,the DoPreallocated method releases (220) its hold on the preallocatedmemory space 108. In addition, it resets (224) the AllocFunctionattribute of the Thread object 114 back to “Normal” so that allsubsequent memory allocations made on behalf of this thread will benormal allocations. With the AllocFunction attribute reset to normal,the DoPrecallocated method does a return to the code that called it. TheDoPreallocated method is thus completed.

At this point, it should be noted that the present invention has minimaleffect on the GC process. Once space within the preallocated memoryspace 108 is allocated to an object, that space is subject to theregular GC operation. Thus, even though the preallocated memory space108 ranges from start pointer to end pointer, the space between thecurrent pointer and the start pointer (representing space that has beenallocated to objects) can be garbage collected. This is a veryadvantageous result because it means that the present invention does notneed a special memory deallocation mechanism to deallocate memory fromthe preallocated memory space 108. Instead, the regular GC mechanism maybe used. As a result, the present invention achieves deterministicbehavior with minimal additional overhead.

Thus far, the invention has been described in the context of asingle-threaded system. It should be noted, however, that with certainenhancements, the invention may be extended to multi-threaded systems.FIG. 4 shows a logical block diagram of a multi-threaded system 400 inwhich the present invention may be implemented.

The system 400 first comprises a memory heap 402 representing all of thedynamic memory space available for accommodating dynamic memoryallocations. As with the heap 102 of FIG. 1, heap 402 comprises occupiedspaces 404, free spaces 406, and preallocated spaces 408. However,notice that the preallocated spaces 408 in FIG. 4 are referred to as“pools” as opposed to “spaces”. This difference in terminology isintended to highlight the fact that the memory pools 408 in heap 402 maybe shared by multiple threads. The sharing of the preallocated memorypools 408 will be described in greater detail in a later section.

System 400 further comprises a memory allocation/execution manager 410for managing the memory heap 402 and the overall flow of execution ofthe system 400. Manager 410 is similar in most respects to the manager110 of FIG. 1. However, manager 410 comprises additional capability formanaging multiple threads of execution. In addition, the Preallocatedfunction of manager 410 is enhanced to provide it with additionalcapability to handle the additional complexity associated with thesharing of a preallocated memory pool 408 by multiple threads. Morespecifically, because multiple threads are sharing the same pool 408,there may be times when multiple threads are concurrently requestingmemory allocations from the same preallocated pool 408. To address thispossibility, the Preallocated function of manager 410 comprisescapability for performing a mutual exclusion operation on the multiplerequests. The mutual exclusion ensures that a memory allocation ispreformed on a preallocated pool 408 for only one thread at a time. Forpurposes of the present invention, the mutual exclusion operation mayimplement any known mutual exclusion methodology, including but notlimited to locks, priority, and arbitration. The Preallocated functionof the manager 410 will be described in greater detail in a latersection. In one embodiment, the manager 410 takes the form of a Java™VM.

System 400 further comprises a PreallocationContext object 412. Object412 is similar to the PreallocationContext object 112 of FIG. 1 in thatit comprises a constructor and three pointer attributes (start, current,and end). In addition, though, object 412 further comprises an Availablemethod and a Replenish method. When invoked, the Available methodreturns a value indicating the amount of space remaining in a currentpreallocated memory pool 408 associated with the PreallocationContextobject 412. This method may be invoked, for example, to determine whento replenish the preallocated memory pool 408.

When it becomes necessary to replenish the pool 408, the Replenishmethod may be invoked. When invoked, this method causes anotherpreallocated memory pool to be allocated. Note that the Replenish methoddoes not cause the existing preallocated memory pool to be deallocatedor released; it simply causes another pool to be preallocated. Toillustrate this, suppose that preallocated memory pool 408 a is thememory pool currently associated with object 412. Suppose further thatthe memory space in pool 408 a is almost completely consumed so that theReplenish method is invoked. When invoked, the Replenish method causesanother memory pool 408 b having the same size as pool 408 a to bepreallocated. Once the new pool 408 b is allocated, the start, current,and end pointers are adjusted to point to the new current pool 408 b.With that done, the new pool 408 b is ready for use. To threadsinteracting with the PreallocationContext object 412, it appears as ifthe preallocated memory pool were erased and made available for reuse.In actuality, however, no erase, deallocation, garbage collection, ormemory release operation was performed. A new pool 408 b was simplycreated. As this discussion shows, it is possible in the presentinvention for multiple preallocated memory pools 408 a, 408 b to beassociated with the same PreallocationContext object 412.

As noted previously in connection with the system of FIG. 1, once memoryspace within a preallocated memory pool is allocated to an object, thatmemory space is subject to regular GC operations. Thus, eventually, allof the allocated space in the memory pools 408 a, 408 b will be garbagecollected and returned to the heap 402. What will not be garbagecollected, however, is the space in each pool 408 a, 408 b that was notallocated to objects. It will be up to the DoPreallocated method of theThread objects 414 a, 414 b to release these spaces, as will beexplained below.

The replenishing of the preallocated memory pools 408 is controlled bythe context manager 416. In one embodiment, the context manager 416executes on its own separate thread and is designed to wake at regularintervals to perform upkeep on the memory pools 408. When it wakes, thecontext manager 416 determines (by invoking the Available method of thePreallocationContext object) whether the available space in the currentpreallocated memory pool associated with the object 412 has droppedbelow a certain threshold. If not, then no action is taken. On the otherhand, if the available space has dropped below the threshold, then thecontext manager 416 invokes the Replenish method of the object 412 tocause a new memory pool to be preallocated. In this manner, the contextmanager 416 prevents the PreallocationContext object 412 from runningout of preallocated space.

System 400 further comprises a plurality of Thread objects 414 a, 414 b,each representing an abstraction of an actual thread of execution. InFIG. 4, for the sake of simplicity, only two Thread objects are shown;however, it should be understood that any number of threads may beaccommodated in system 400. For the most part, Thread objects 414 a, 414b are similar to the Thread object 114 of FIG. 1. however, there is adifference in the DoPreallocated method of objects 414 a, 414 b which isworth noting. Rather than taking in a Size parameter as one of thearguments, the DoPreallocated method of objects 414 a, 414 b takes in aspecific PreallocationContext object reference. By taking in a specificPreallocationContext object reference as argument, the DoPrecallocatedmethod of objects 414 a, 414 b makes it possible for differentDoPreallocated method calls from different threads to reference the samePreallocationContext object. As a result, it is possible for multiplethreads to share the same PreallocationContext. In addition to taking ina different argument, the implementation of the DoPreallocated method ofobjects 414 a, 414 b is also different. This difference will be madeclear in the following discussion.

With reference to the system diagram of FIG. 4 and the flow diagrams ofFIGS. 5 and 6, the operation of the multi-threaded system 400 will nowbe described. Initially, suppose that the Thread objects 414 a, 414 bhave been instantiated and that their Start methods have been invoked sothat they have been associated with actual threads of execution. Supposefurther that these threads of execution have been executing sets of codeand that during such execution, one of the threads instantiates thePreallocationContext object 412. During instantiation, the constructorof the PreallocationContext object 412 causes a preallocated memory pool408 a having a certain size N to be allocated on the heap 402. The startand current pointers are set to point to the beginning 420 of thepreallocated memory space 408 a, and the end pointer is set to point tothe end 424 of the preallocated memory space 408 a. The preallocatedmemory space 408 a is now ready for use.

Now, suppose that in the process of executing code, one of the threadsencounters a DoPreallocated method call which passes along aPreallocationContext parameter PC referencing the PreallocationContextobject 412, and an Action parameter AC. This causes the DoPreallocatedmethod of the Thread object class to be invoked. Once invoked, theDoPreallocated method determines (504, FIG. 5) which thread invoked it.In this particular example, it will be assumed that it is the threadassociated with the Thread object 414 a. Once that determination ismade, the DoPreallocated method sets (516) the AllocFunction attributeof the Thread object 414 a to “Preallocated”. This causes the allocationmanager 410 to perform all subsequent memory allocations for this threadusing the Preallocated allocation function. Once the AllocFunctionattribute is set, the DoPreallocated method causes the code referencedby the Action parameter AC to be executed (520). While executing thiscode, one or more memory allocations will most likely need to beperformed. Each time a memory allocation is needed, the allocationmanager 410 is invoked.

When invoked, the manager 410 receives (604, FIG. 6) the memoryallocation request. It then determines (608) which thread made theallocation request, and gets the AllocFunction value for that thread(612). Once that is done, the manager 410 checks (620) the AllocFunctionattribute of that thread. If AllocFunction is set to “Normal”, then theNormal allocation function is used to perform the memory allocation, inwhich case, the allocation is made (624) from the free space 106 on theheap 402. Because this is a normal allocation, it may trigger a GCoperation. On the other hand, if the AllocFunction attribute is set to“Preallocated” (as is the case in this example), then the allocationmanager 410 will use the Preallocated function to perform the memoryallocation. Under the Preallocated function, the manager 410 does notallocate memory from the free space 406 but rather from the preallocatedmemory pool 408 a associated with the PreallocationContext specified inthe DoPrecallocated method call. As a result, the memory allocation isguaranteed to not cause a GC operation, and to be free of fragmentationeffects.

According to the Preallocated function, before memory is allocated fromthe preallocated memory pool 408 a, the manager 410 first performs amutual exclusion operation (626), if necessary. As noted previously, ina multi-threaded system, it is possible for multiple threads toconcurrently request a memory allocation from the samePreallocationContext. If that happens, the manager 410 will need toperform a mutual exclusion operation on the multiple requests to ensurethat only one request is processed at a time. At this point, it shouldbe noted that if a mutual exclusion operation is performed, the memoryallocation time may vary. Despite this variance, though, the allocationtime behavior will still be deterministic. To elaborate, suppose thatfive threads concurrently request a memory allocation from the samePreallocationContext. Usually, the memory allocation operation requiresan X amount of time. Because of the contention, however, some of thesethreads will have to wait, and hence, the memory allocation time will belonger. However, since the present invention guarantees that once athread gets access to the PreallocationContext, the actual memoryallocation operation will require a constant X amount of time, it isknown that at worst, the memory allocation time for any of the fivethreads will be 5X. Thus, even though the wait may cause allocationtimes to vary, the behavior of the memory allocation mechanism willstill be deterministic and predictable. It is this determinism that isusually required in systems such as real time systems.

Once the mutual exclusion operation (if necessary) is performed, memorymay be allocated from the preallocated memory pool 408 a. In oneembodiment, memory allocation is performed as follows. Initially, adetermination is made (628) as to whether there is sufficient space inthe preallocated memory pool 408 a to satisfy the memory allocationrequest. This may be done by comparing the amount of free space in thepreallocated memory pool 408 a associated with the PreallocationContext412 (ascertained by calling the Available method) with the amount ofspace requested. If there is not enough free space to satisfy therequest, then an “out of memory” error is generated (636). No GCoperation is invoked. On the other hand, if there is sufficient space inthe preallocated memory pool 408 a to satisfy the request, then thememory allocation is performed using the preallocated memory pool. Inone embodiment, memory is allocated from pool 408 a by incrementing thecurrent pointer of the PreallocationContext object by the amount ofspace used to fill the memory request. Memory allocation using apreallocated memory pool 408 a associated with a specificPreallocationContext 412 is thus performed.

Referring again to FIG. 5, the set of code referenced by the Actionparameter AC continues to be executed until execution is completed. Atthat point, there is a return to the DoPreallocated method. Upon return,the DoPreallocated method determines (524) whether any other threads arecurrently using the memory pool 408 a from which the DoPreallocatedmethod is exiting. In one embodiment, to enable the DoPreallocatedmethod to make this determination, a reference count is maintained bythe PreallocationContext object 412 for each of the preallocation memorypools 408 a, 408 b associated with the object 412. Whenever a threadenters a pool 408 a, 408 b, the reference count associated with thatpool is incremented. Whenever a thread leaves a pool 408 a, 408 b, thereference count associated with that pool is decremented. Thus, bydetermining whether the reference count associated with a pool 408 a,408 b has reached zero, the DoPreallocated method can determine whetherany other threads are currently using that pool.

If no other threads are using the pool 408 a from which theDoPreallocated method is exiting, then the hold on the pool 408 a isreleased (528). Thereafter, the DoPreallocated method resets (532) theAllocFunction attribute of the Thread object 414 a back to “Normal” sothat all subsequent memory allocations made on behalf of this threadwill be normal allocations. With the AllocFunction attribute reset tonormal, the DoPreallocated method does a return to the code that calledit. The DoPreallocated method is thus completed.

Hardware Overview

FIG. 7 is a block diagram that illustrates a computer system 700 inwhich an embodiment of the invention may be implemented. Computer system700 includes a bus 702 or other communication mechanism forcommunicating information, and a processor 704 coupled with bus 702 forprocessing information. Computer system 700 also includes a main memory706, such as a random access memory (RAM) or other dynamic storagedevice, coupled to bus 702 for storing information and instructions tobe executed by processor 704. In addition to being used for implementingthe heaps 102, 402, main memory 706 also may be further used for storingtemporary variables or other intermediate information during executionof instructions to be executed by processor 704. Computer system 700further includes a read only memory (ROM) 708 or other static storagedevice coupled to bus 702 for storing static information andinstructions for processor 704. A storage device 710, such as a magneticdisk or optical disk, is provided and coupled to bus 702 for storinginformation and instructions.

Computer system 700 may be coupled via bus 702 to a display 712, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 714, including alphanumeric and other keys, is coupledto bus 702 for communicating information and command selections toprocessor 704. Another type of user input device is cursor control 716,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 704 and forcontrolling cursor movement on display 712. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

According to one embodiment, the functionality of the present inventionis provided by computer system 700 in response to processor 704executing one or more sequences of one or more instructions contained inmain memory 706. Such instructions may be read into main memory 706 fromanother computer-readable medium, such as storage device 710. Executionof the sequences of instructions contained in main memory 706 causesprocessor 704 to perform the process steps described herein. Inalternative embodiments, hard-wired circuitry may be used in place of orin combination with software instructions to implement the invention.Thus, embodiments of the invention are not limited to any specificcombination of hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 704 forexecution. Such a medium may take many forms, including but not limitedto, non-volatile media, volatile media, and transmission media.Non-volatile media includes, for example, optical or magnetic disks,such as storage device 710. Volatile media includes dynamic memory, suchas main memory 706. Transmission media includes coaxial cables, copperwire and fiber optics, including the wires that comprise bus 702.Transmission media can also take the form of acoustic or electromagneticwaves, such as those generated during radio-wave, infra-a-red, andoptical data communications.

Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, any other optical medium, punchcards, papertape, anyother physical medium with patterns of holes, a RAM, a PROM, and EPROM,a FLASH-EPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to processor 704 forexecution. For example, the instructions may initially be carried on amagnetic disk of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using, a modem. A modem local to computer system 700 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 702. Bus 702 carries the data tomain memory 706, from which processor 704 retrieves and executes theinstructions. The instructions received by main memory 706 mayoptionally be stored on storage device 10 either before or afterexecution by processor 704.

Computer system 700 also includes a communication interface 718 coupledto bus 702. Communication interface 718 provides a two-way datacommunication coupling to a network link 720 that is connected to alocal network 722. For example, communication interface 718 may be anintegrated services digital network (ISDN) card or a modem to provide adata communication connection to a corresponding type of telephone line.As another example, communication interface 718 may be a local areanetwork (LAN) card to provide a data communication connection to acompatible LAN. Wireless links may also be implemented. In any suchimplementation, communication interface 718 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 720 typically provides data communication through one ormore networks to other data devices. For example, network link 720 mayprovide a connection through local network 722 to a host computer 724 orto data equipment operated by an Internet Service Provider (ISP) 726.ISP 726 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 728. Local network 722 and Internet 728 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 720and through communication interface 718, which carry the digital data toand from computer system 700, are exemplary forms of carrier wavestransporting the information.

Computer system 100 can send messages and receive data, includingprogram code, through the network(s), network link 720 and communicationinterface 718. In the Internet example, a server 730 might transmit arequested code for an application program through Internet 728, ISP 726,local network 722 and communication interface 718. The received code maybe executed by processor 704 as it is received, and/or stored in storagedevice 710, or other non-volatile storage for later execution. In thismanner, computer system 700 may obtain application code in the form of acarrier wave.

At this point, it should be noted that although the invention has beendescribed with reference to a specific embodiment, it should not beconstrued to be so limited. Various modifications may be made by thoseof ordinary skill in the art with the benefit of this disclosure withoutdeparting from the spirit of the invention. Thus, the invention shouldnot be limited by the specific embodiments used to illustrate it butonly by the scope of the appended claims.

What is claimed is:
 1. In a computer system having a memory heap, thememory heap comprising free space and allocated space, a method forachieving deterministic memory allocation response in the system,comprising: allocating from free space on the heap a preallocated memoryspace; receiving a first memory allocation request from a first thread;and processing said first memory allocation request by allocating memoryfrom said preallocated memory space rather than from the free space onthe heap, thereby enabling processing of said first memory allocationrequest to be performed without triggering a memory reclamationoperation.
 2. The method of claim 1, wherein said preallocated memoryspace is contiguous.
 3. The method of claim 2, wherein said firstrequest is processed by allocating at least a subset of saidpreallocated memory space, and wherein said subset, once allocated, issubject to release back to the heap via a garbage collection operation.4. The method of claim 1, further comprising: receiving a second memoryallocation request from a second thread requesting memory allocationfrom said preallocated memory space; and processing said second memoryallocation request by allocating memory from said preallocated memoryspace rather than from the free space on the heap.
 5. The method ofclaim 4, wherein said first and second memory allocation requests arereceived concurrently, and wherein, prior to processing either request,a mutual exclusion operation is performed to determine which request toprocess first.
 6. The method of claim 5, wherein after said mutualexclusion operation is performed, each of said first and second requestsare processed in substantially equal amounts of time.
 7. The method ofclaim 4, wherein said first request is processed by allocating a firstsubset of said preallocated memory space, wherein said second request isprocessed by allocating a second subset of said preallocated memoryspace, and wherein said first and second subsets, once allocated, aresubject to release back to the heap via a garbage collection operation.8. The method of claim 4, further comprising: determining whetheravailable space in said preallocated memory space has dropped below acertain threshold; and in response to a determination that the availablespace in the preallocated memory space has dropped below a certainthreshold, allocating from the free space on the heap anotherpreallocated memory space for use in processing future memory allocationrequests.
 9. A computer system capable of achieving deterministic memoryallocation response, comprising: a memory heap comprising free space andallocated space; a mechanism for allocating from said free space on saidheap a preallocated memory space; a mechanism for receiving a firstmemory allocation request from a first thread; and a mechanism forprocessing said first memory allocation request by allocating memoryfrom said preallocated memory space rather than from said free space onsaid heap, thereby enabling said first memory allocation request to beprocessed without triggering a memory reclamation operation.
 10. Thesystem of claim 9, wherein said preallocated memory space is contiguous.11. The system of claim 10, wherein said first request is processed byallocating at least a subset of said preallocated memory space, andwherein said subset, once allocated, is subject to release back to saidheap via a garbage collection operation.
 12. The system of claim 9,further comprising: a mechanism for receiving a second memory allocationrequest from a second thread requesting memory allocation from saidpreallocated memory space; and a mechanism for processing said secondmemory allocation request by allocating memory from said preallocatedmemory space rather than from said free space on said heap.
 13. Thesystem of claim 12, wherein said first and second memory allocationrequests are received concurrently, and wherein said system furthercomprises: a mechanism for performing a mutual exclusion operation,prior to processing either request, to determine which request toprocess first.
 14. The system of claim 13, wherein after said mutualexclusion operation is performed, each of said first and second requestsare processed in substantially equal amounts of time.
 15. The system ofclaim 12, wherein said first request is processed by allocating a firstsubset of said preallocated memory space, wherein said second request isprocessed by allocating a second subset of said preallocated memoryspace, and wherein said first and second subsets, once allocated, aresubject to release back to said heap via a garbage collection operation.16. The system of claim 12, further comprising: a mechanism fordetermining whether available space in said preallocated memory spacehas dropped below a certain threshold; and a mechanism for allocating,in response to a determination that the available space in thepreallocated memory space has dropped below a certain threshold, fromsaid free space on said heap another preallocated memory space for usein processing future memory allocation requests.
 17. A computer programproduct for achieving deterministic memory allocation response in asystem having a memory heap, the memory heap comprising free space andallocated space, the computer program product comprising: code forcausing one or more processors to allocate from the free space on theheap a preallocated memory space; code for causing one or moreprocessors to receive a first memory allocation request from a firstthread; and code for causing one or more processors to process saidfirst memory allocation request by allocating memory from saidpreallocated memory space rather than from the free space on the heap,thereby enabling processing of said first memory allocation request tobe performed without triggering a memory reclamation operation.
 18. Thecomputer program product of claim 17, wherein said preallocated memoryspace is contiguous.
 19. The computer program product of claim 18,wherein said first request is processed by allocating at least a subsetof said preallocated memory space, and wherein said subset, onceallocated, is subject to release back to the heap via a garbagecollection operation.
 20. The computer program product of claim 17,further comprising: code for causing one or more processors to receive asecond memory allocation request from a second thread requesting memoryallocation from said preallocated memory space; and code for causing oneor more processors to process said second memory allocation request byallocating memory from said preallocated memory space rather than fromthe free space on the heap.
 21. The computer program product of claim20, wherein said first and second memory allocation requests arereceived concurrently, and wherein said computer program product furthercomprises: code for causing one or more processors to perform, prior toprocessing either request, a mutual exclusion operation to determinewhich request to process first.
 22. The computer program product ofclaim 21, wherein after said mutual exclusion operation is performed,each of said first and second requests are processed in substantiallyequal amounts of time.
 23. The computer program product of claim 20,wherein said first request is processed by allocating a first subset ofsaid preallocated memory space, wherein said second request is processedby allocating a second subset of said preallocated memory space, andwherein said first and second subsets, once allocated, are subject torelease back to the heap via a garbage collection operation.
 24. Thecomputer program product of claim 20, further comprising: code forcausing one or more processors to determine whether available space insaid preallocated memory space has dropped below a certain threshold;and code for causing one or more processors to allocate, in response toa determination that the available space in the preallocated memoryspace has dropped below a certain threshold, from the free space on theheap another preallocated memory space for use in processing futurememory allocation requests.